1. Field of the Invention
The present invention generally relates to an application authentication method and electronic device supporting the same that can authenticate an application requesting an operation at run time.
2. Description of the Related Art
Advanced electronic devices may contain a non-trusted execution environment (NTEE) and a trusted execution environment (TEE). The NTEE contains an ordinary Operating System (OS), drivers, middleware, and applications. An example of such a system is Android, which may contain the Linux kernel, device drivers, the Android execution environment, Android middleware, and applications. The TEE may contain security critical components that are accessed by NTEE components at run time to execute specific security related operations. Typically, the TEE may contain a secure OS, secure drivers, secure middleware, and trusted applications (TA). In addition, the TEE may contain a special module that handles communication between the NTEE and the TEE—the monitor. To preserve the integrity of the TEE, all components thereof are governed by a secure boot, such that the integrity of the TEE is examined at system boot time.
NTEE components may request the TEE to perform certain security critical operations. Such an NTEE component may be referred to as an NTEE client. Examples of NTEE clients may include NTEE OS native applications, Android applications, and the like. Typically, a TEE operation request issued by an NTEE client is received by the NTEE OS middleware and is forwarded to the NTEE driver, which is responsible for communication with the TEE. The NTEE client may also communicate directly with the TEE driver.
The TEE driver forwards the request for TEE operation to the monitor. The monitor switches to the TEE and passes the request to a Request Handler of the secure OS. The secure OS identifies a suitable trusted application to handle the request and sends the request to the identified trusted application to perform a specified operation. The secure OS may send the request directly to the trusted application or send the same through the secure middleware layer. Upon receiving the request, the trusted application executes the requested operation.
Meanwhile, a TEE operation request may contain some data to be processed by a corresponding trusted application. A TEE operation request may also contain a reference to data in the NTEE memory that has to be processed. In addition, a TEE operation request may contain a reference to the NTEE memory where results of the TEE operation are to be placed. The system memory is configured in such a way that the NTEE memory is fully accessible by the TEE secure OS for read and write operations and the TEE memory is blocked from any access by NTEE components.
Since a trusted application in the TEE may perform a security critical operation only for a specific NTEE component, it is important for the trusted application to check the integrity of an NTEE client that has requested such an operation.
Existing solutions, such as ARM TrustZone Client API Specification 3.0 and Global Platform Client API Specification 1.0, provide a mechanism for such an NTEE client integrity check. Namely, both specifications instruct the NTEE environment to collect specific information about the client and send the collected information to the TEE trusted application through the TEE driver as so-called “log-in information”. For example, the NTEE environment may check integrity of the NTEE client by calculating a hash of the NTEE client executable file. Another example is to forward some NTEE client supplied data as an authentication token for the TEE trusted application.
Such an approach requires that all NTEE components engaged in NTEE client authentication be trusted by the TEE trusted application. Namely, the TEE trusted application should trust the NTEE OS, NTEE driver and NTEE middleware. However, practical implementation of the NTEE often assumes that some of the NTEE components may be freely changed and thus cannot be trusted by the TEE.
For example, the NTEE middleware may be changed by malicious software in such a way that a hash of a malicious NTEE client executable file is substituted by the hash of the valid NTEE client executable file. The NTEE driver can be replaced with a different one that intercepts client identification data and provides the same to a malicious NTEE client.
Under the condition that NTEE components can be changed by malicious software, existing solutions based on NTEE client authentication using NTEE components cannot provide a high level of security. Hence, the TEE trusted application cannot fully trust the NTEE client authentication data provided by NTEE components.